Embodiments of the present invention generally relate to handling information related to financial and other transactions. More specifically, some embodiments of the present invention relate to methods and systems for identifying applications used in communicating data between a presentation instrument and a terminal in order to conduct a financial transaction. Embodiments of the invention further include using a dynamic cryptogram for securely handling the financial transaction.
Today, merchants and service providers accept various forms of payment. Many merchants will accept cash, credit cards, debit cards, stored-value cards, checks, and promotional items such as coupons. Additionally, various forms of wireless or contactless devices have been introduced for use in various types of transactions. For example, contactless transaction initiation is often performed with a “smart” card or other presentation instrument such as a key fob or a mobile device such as a cell phone or Personal Digital Assistant (PDA) containing a memory and a processor. Such a card or device typically also includes Radio-Frequency IDentification (“RFID”) or Near-Field Communications (NFC) components for contactless communication with a Point-Of-Sale (POS) device. The information stored in the memory of the device and communicated via the RFID or NFC components to the POS device is generally similar or identical to the information recorded on the magnetic stripe of a card, i.e., account number etc. Thus, in some cases, such devices may be utilized instead of more conventional cards.
However, such devices and/or transactions are vulnerable to a number of different types of attacks from identity thieves or other criminals. For example, devices capable of skimming transmissions between the merchant's reader and cards or other devices can be placed near the NFC reader to read the transaction information, including the account number, when a card or device is read at the POS device, making the transaction particularly vulnerable if the account number is transmitted in clear text (unencrypted) form. In another example, illegal portable readers can be used which, when brought into proximity with a card or other device can read the account information from the card even while it is being carried in a wallet or purse. In yet another example, transactions or transaction information that are transmitted through a payment processor's network or other network may be intercepted and read to obtain account numbers and/or other information.
In an effort to prevent such attacks, encryption is sometimes used to protect the account number on the card or device. Such encryption utilizes an encrypted account number on the card or device or an encryption key that is loaded into the card or device that is derived from an institution level key (i.e., it applies to many cards) and the card number. However, using a common key can lead to a compromise of a large number of cards if the institution's encryption key is exposed. A common defense against this risk is to derive a card level key using the common institution level key and some card level attributes such as the Primary Account Number (PAN), though this technique has exposure risk as well. This key exposure can result from a failure in business processes of the issuer to protect the key or an assault on a single chip, e.g., using electron-microscopy to expose the derived key followed by a DES assault to derive the institution's key. If the institution key is compromised, all transactions for all cards or devices with this institution's key are potentially exposed. Therefore, a new key must be created and a possibly large number of cards re-issued. Hence, there is a need in the art for improved methods and systems for securely handling a financial transaction.
In addition, with the increasing use of mobile devices for conducting transactions, there has been a corresponding increase in the numbers of different payment processors and issuers involved in such transactions. The types of data and the data format for transactions may vary, depending not only on the payment processor, but the issuer and the type of account involved. As one example, for a debit card account, a PIN may need to be part of the data transmitted by the user to authenticate the transactions. For a credit card account, PINs are typically not required. Thus different types of accounts from the same card issuer may require different data to conduct a transaction. As another example, different issuers may have different card data or data formats required by the systems they use for processing a financial transaction. Also, an account number might be useful to establish the type of account (and the nature of the data to be transmitted), but for the reasons given above, an account number being sent in clear text form from a presentation instrument to a reader (to establish the data to be transmitted) involves increased risk.
The establishment of card data formats to be transmitted between the presentation instrument device and terminal reader (e.g., at a POS device) is done by an application resident at both the device and at the POS device. Such applications are sometimes referred to as a “chip” application or a “card” application, since they are stored in memory associated with a processor chip found on a presentation instrument or smart card device. As long as the device and the reader both have the same application, the required data can be transmitted and received in the proper format. During the initial steps of conducting a transaction, a presentation instrument and a reader at a POS device will verify that they each do, in fact, have the same card application. While such applications are identified by an application ID that can distinguish between applications (and the providers of those applications), the increasing numbers of transactions using mobile devices necessitates some further means for distinguishing between applications. As an example, a single provider (e.g., payment processor) may need to have many different applications depending on the issuer (for which it is processing payment) and the many different kinds of accounts maintained by each issuer. Current application IDs do not permit systems to efficiently distinguish between applications.